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Abstract 

Ordinary digital signatures have an inherent weakness: if the secret key is leaked, then all signatures, 
even the ones generated before the leak, are no longer trustworthy. Forward-secure digital signatures were 
recently proposed to address this weakness: they ensure that past signatures remain secure even if the 
current secret key is leaked. 

We propose the first forward-secure signature scheme for which both signing and verifying are as 
efficient as for one of the most efficient ordinary signature schemes (Guillou-Quisquater): each requiring 
just two modular exponentiations with a short exponent. All previously proposed forward-secure signature 
schemes took significantly longer to sign and verify than ordinary signature schemes. 

Our scheme requires only fractional increases to the sizes of keys and signatures, and no additional 
public storage. Like the underlying Guillou-Quisquater scheme, our scheme is provably secure in the 
random oracle model. 
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1 Introduction 

The Purpose of Forward Security. Ordinary digital signatures have a fundamental limitation: if the 
secret key of a signer is compromised, all the signatures (past and future) of that signer become worthless. 
This limitation undermines, in particular, the non-repudiation property that digital signatures are often 
intended to provide. Indeed, one of the easiest ways for Alice to repudiate her signatures is to post her secret 
key anonymously somewhere on the Internet and claim to be a victim of a computer break-in. In principle, 
various revocation techniques can be used to prevent users from accepting signatures with compromised 
keys. However, even with these techniques in place, the users who had accepted signatures before the keys 
were compromised are now left at the mercy of the signer, who could (and, if honest, would) re-issue the 
signatures with new keys. 

Forward- secure signature schemes, first proposed by Anderson in [And97] and formalized by Bellare and 
Miner in [BM99], are intended to address this limitation. Namely, the goal of a forward- secure signature 
scheme is to preserve the validity of past signatures even if the current secret key has been compromised. 
This is accomplished by dividing the total time validity period of a given public key into T time periods, and 
using a different secret key in each time period (while the public key remains fixed). Each subsequent secret 
key is computed from the current secret key via a key update algorithm. The time period during which a 
message is signed becomes part of the signature. Forward security property means that even if the current 
secret key is compromised, a forger cannot forge signatures for past time periods. 

Prior Schemes. Prior forward- secure signature schemes can be divided into two categories: those that 
use (in a black-box manner) arbitrary signature schemes, and those that modify specific signature scheme. 

In the first category, the schemes use some method in which a master public key is used to certify (perhaps 
via a chain of certificates) the current public key for a particular time period. Usually, these schemes require 
increases in storage space by noticeable factors in order to maintain the current (public) certificates and 
the (secret) keys for issuing future certificates. They also require longer verification times than ordinary 
signatures do, because the verifier needs to verify the entire certificate chain in addition to verifying the 
actual signature on the message. There is, in fact, a trade-off between storage space and verification time. 
The two best such schemes are the tree-based scheme of Bellare and Miner [BM99] 1 (requiring storage of 
about lgT secret keys and non-secret certificates, and verification of about lgT ordinary signatures) and 
the scheme of Krawczyk [KraOO] (requiring storage of T non-secret certificates, and verification of only 2 
ordinary signatures). 

In the second category, there have been only two schemes proposed so far (both in the random oracle 
model): the scheme of Bellare and Miner [BM99] based on the Fiat-Shamir scheme [FS86], and the scheme 
of Abdalla and Reyzin [AROO] based the 2*-th root scheme [0088, OS90, Mic94]. While needing less space 
than the schemes in the first category, both [BM99] and [AROO] require signing and verification times that 
are linear in T. 

Our Results. We propose a scheme in the second category, based on one of the most efficient ordinary 
signature schemes, due to Guillou-Quisquater [GQ88]. It uses just two modular exponentiations with short 
exponents for both signing and verifying. 

Ours is the first forward- secure scheme where both signing and verifying are as efficient as the underlying 
ordinary signature scheme. Moreover, in our scheme the space requirements for keys and signatures are 
nearly the same to those in the underlying signature scheme (for realistic parameter values, less than 50% 
more) . 

The price of our scheme is in the running times of its key generation and update routines: both are linear 
in T (however, so is key generation in [KraOO], [BM99] and [AROO]). We consider this a worthwhile price to 
pay for such efficient signing and verifying, because key generation and update are (presumably) performed 

1 Some improvements to tree-based scheme of [BM99] (not affecting this discussion) have been proposed in [AROO] and [MI]. 



much less frequently than signing and verifying. Moreover, we show that, if we are willing to tolerate secret 
storage of 1 + log 2 T values, we can reduce the running time of the key update algorithm to be logarithmic 
in T without affecting the other components (this, rather unexpectedly, involves a very nice application of 
pebbling). For realistic parameter values, the total storage requirements, even with these additional secrets, 
are still less than in all prior schemes; the only exception is the [AROO] scheme, which has very inefficient 
signing and verifying. 

Our scheme is provably secure in the random oracle model based on a variant of the strong RSA as- 
sumption. 

2 Forward-secure digital signature schemes 

2.1 Definitions 

This section closely follows their first formal definition of forward secure signatures proposed by Bellare and 
Miner [BM99]. Their definition, in turn, is based on the Goldwasser, Micali and Rivest's [GMR88] definition 
of (ordinary) digital signatures secure against adaptive chosen message attacks. 

Key Evolution. The approach taken by forward- secure schemes is to change the secret key periodically 
(and require the owner to properly destroy the old secret key 2 ). Thus we consider the time to be divided 
into time periods; at the end of each time period, a new secret key is produced and the old one is destroyed. 
The number of the time period when a signature was produced is part of the signature and is input to the 
verification algorithm; signatures with incorrect time periods should not verify. 

Of course, while modifying the secret key, one would like to keep the public key fixed. This can be achieved 
by use of a "master" public key, which is somehow used to certify the temporary public key for the current 
time period (note however, than one needs to be careful not to keep around the corresponding "master" 
secret key — its presence would defeat the purpose of forward security) . The first simple incarnation of this 
approach was proposed by [And97]; a very elegant tree-based solution was proposed by [BM99]; another 
approach, based on generating all of the certificates in advance, was put forward by [KraOO]. However, in 
general, one can conceive of schemes where the public key stays fixed but no such certificates of per-period 
public keys are present (and, indeed, such schemes are proposed in [BM99, AROO], as well as in this paper). 

The notion of a key-evolving signature scheme captures, in full generality, the idea of a scheme with a 
fixed public key and a varying secret key. It is, essentially, a regular signature scheme with the additions of 
time periods and the key update algorithm. Note that this notion is purely functional: security is addressed 
separately, in the definition of forward security (which is the appropriate security notion for key-evolving 
signature schemes). 

Thus, a key-evolving digital signature scheme is a quadruple of algorithms, FSIG = (FSIG.key, FSIG. update, 
FSIG.sign, FSIG.vf), where: 

• FSIG.key, the key generation algorithm, is a probabilistic algorithm which takes as input a security 
parameter k € N (given in unary as l k ) and the total number of periods T and returns a pair (SK\, PK), 
the initial secret key and the public key; 

• FSIG.sign, the (possibly probabilistic) signing algorithm, takes as input the secret key SKj= {Sj,j,T) 
for the time period j <T and the message M to be signed and returns the signature (j, sign) of M for 
time period j; 

• FSIG. update, the (possibly probabilistic) secret key update algorithm, takes as input the secret key SKj 
for the current period j < T and returns the new secret key SK j + \ for the next period j + 1. 

2 Obviously, if the key owner does not properly destroy her old keys, an attacker can obtain them and thus forge the "old" 
signatures. Indeed, proper deletion of the old keys may be a non-trivial task. However, insisting that achieving such a proper 
deletion of the old keys is the responsibility of the key owner is a reasonable requirement — certainly more reasonable than 
insisting that she guarantee the secrecy of her active keys. 



• FSIG.vf, the (deterministic) verification algorithm, takes as input the public key PK , a message M, and 
a candidate signature (j, sign), and returns 1 if (j, sign) is a valid signature of M or 0, otherwise. It is 
required that FSIG.vf pk(M, FSIG.sign s/f (M)) = 1 for every message M and time period j. 

We adopt the convention that SKt+i is the empty string and FSIG.update^^y returns SKt+\- 

When we work in the random oracle model, all the above-mentioned algorithms would have an additional 
security parameter, l l , and oracle access to a public hash function H : {0, 1}* — > {0, 1} ; , which is assumed 
to be random in the security analysis. 

Forward Security. Forward security captures the notion that it should be computationally infeasible 
for any adversary to forge a signature for any past time period even in the event of exposure of the current 
secret key. Of course, since the update algorithm is public, nothing can be done with respect to future secret 
keys, except for revoking the public key (thus invalidating all signatures for the time period of the break-in 
and thereafter). To define forward security formally, the notion of a secure digital signature of [GMR88] is 
extended in [BM99] to take into account the ability of the adversary to obtain a key by means of a break-in. 

Intuitively, in this new model, the forger first conducts an adaptive chosen message attack (cma), re- 
questing signatures on messages of its choice for as many time periods as he desires. Whenever he chooses, 
he "breaks in" : requests the secret key SKf, for the current time period b and then outputs a signature on 
a message M of his choice for a time period j < b. The forger is considered to be successful if the signature 
is valid and the pair (M,j) was not queried during cma. 

Formally, let the forger F = (F.cma, F. forge). For {PK,SK ) A FSIG.key(Jfe, . . . ,T), F.cma, given PK 
and T, outputs (CM, 6), where b is the break-in time period and CM is a set of adaptively chosen message- 
period pairs (the set of signatures sign(CM) of the current set CM is available to F at all times, including 
during the construction of CM) 3 . Finally, F.forge outputs (M,j,sig) <- F.forge(CM, sign(CM), SK b ). 
We say that F is successful if (M,j) # CM,j < b, and FSIG.vf P /f (M, (j, sig)) = 1. (Note: formally, the 
components of F can communicate all the necessary information, including T and 6, via CM be considered 
independent, because they communicate state information via T, 6, as well as forger state information can 
be communicated to F.forge via CM.) 

Define Succ fwslg (FSIG[&, T], F) to be the probability (over coin tosses of F and FSIG) that F is successful. 
Define the insecurity function InSec wslg (FSIG[&,T],£, g s ; g ) of FSIG to be the maximum, over all algorithms 
F that are restricted to running time t and g s ; g signature queries, of Succ wslg (FSIG[&,T], F). 

The insecurity function above follows the "concrete security" paradigm and gives us a measure of how 
secure or insecure the scheme really is. Therefore, we want its value to be as small as possible. Our goal in 
a security proof will be to find an upper bound for it. 

The above definition can be translated to the random oracle model in a standard way [BR93]: by 
introducing an additional security parameter l l , allowing all algorithms the access to the random oracle 
H : {0,1}* — > {0,1}, and considering (/hash, the number of queries to the random oracle, as one more 
parameter for the forger. 

2.2 Underlying hard problem 

We use a variant of the strong RSA assumption, with the restriction that the modulus is a product of 
so-called "safe" primes. That is, let n be a product of two randomly generated [~&/2]-bit "safe" primes pi,P2 

3 Note that the [BM99] definition, which captures what F can do in practice, allows the messages-period pairs to be added 
to CM only in the order of increasing time periods and without knowledge of any secret keys. However, allowing the forger 
to construct CM in arbitrary order, and even to obtain SK b in the middle of the CM construction (so that some messages 
be constructed by the forger with the knowledge of SKb) would not affect our (and their) results. Similarly, the forger can be 
allowed to obtain more than one secret key — we only care about the earliest period b for which the secret key is given to the 
forger. So, the forger may adaptively select some messages which are signed for him, then request some period's secret key; 
then adaptively select more messages and again request a key, etc. 



(that is, pi = 2qi + 1 where % itself is a prime), and let a <— Z*. Let I be an integer. We assume that it is 
hard to take a root a modulo n of any degree r, 1 < r < 2 l+l . 

More formally, let A be the adversary for this problem. Consider the following experiment. 

Experiment Break-Strong-RSA(&, I, A) 

Randomly choose two primes q\ and q 2 of length \k/2\ — 1 each 

such that 2qi + 1 and 2q2 + 1 are both prime. 
pi «- 2q 1 + 1; p 2 -<- 2g 2 + 1; n «- p\p 2 
Randomly choose a € Z*. 
(/3,r) ^^(n,a) 
If 1 < r < 2' +1 and f3 r = a (mod n) then return 1 else return 

Denote Succ(j4, k, I) denote the probability that A the above experiment returns 1, and let InSec (k, I, t) 

be the maximum of Succ(j4, k, I) over all the adversaries A who run in time at most t. 

Our results will be meaningful only if InSec (k, I, t) is small. 

We note that our assumption can be reduced to subexponential hardness of RSA. Namely, if the proba- 
bility of inverting the RSA function in time t for a randomly chosen exponent is at least 2 ke for some e, and 
A; e — Z — 1 is sufficiently large, then InSec (k, I, t) is small. 

3 Our tools 

A Bit of Mathematical Background. It will be helpful to first introduce the following two statements. 
They were first pointed out by Shamir [Sha83] in the context of generation of pseudorandom sequences based 
on the RSA function. 

Proposition 3.1 Let G be any group. Suppose e\, e 2 € Z are such that gcd(ei, e 2 ) = 1. Given a, b € G such 
that and a ei = 6 62 , one can compute c such that c 62 = a in 0(lg(ei + e 2 )) group and arithmetic operations. 

Proof: Using Euclid's extended gcd algorithm, within 0(lg(ei + e 2 )) arithmetic operations compute /i, f 2 , 
such that ei/i + 62/2 = 1- Compute c = a^b? 1 , with 0(lg(/i -I-/2)) = 0(lg(ei +e 2 )) group operations. Then 
c e 2 = a ^h\fih = a ^h a eih = a . I 



Lemma 3.2 Let G be a finite group. Suppose e\,e 2 € Z are such that gcd(ei, e 2 ) = g and gcd(g, |G|) = 1. 
Given a, b € G, such 
arithmetic operations. 



Given a,b € G, such that a ei = b e2 , one can compute c such that c e2 ' 9 = a in 0(lg ei+e2 ) group and 



Proof: Since gcd(g,|G|) = 1, (z 9 = 1) ^> (z = 1) for any z G G. Let e[ = e\/g, e' 2 = e 2 /g. Then 
(a e i/6 e 2) 9 = 1, so a e i = 6 e 2, so we can apply and Proposition 3.1 to get c such that c e 2 = a. I 

The GQ Scheme. In [GQ88], Guillou and Quisquater propose the following three- round identification 
scheme. Let k and / be two security parameters. The prover's secret key consists of a k-bit modulus 
n (a product of two random primes pi,p 2 ), an (/ + l)-bit exponent e that is relatively prime to 4>{n) = 
(pi — l)(p 2 — 1), and a random s € Z*. The public key consists of n, e and v where v = l/s e (mod n). 

In the first round, the prover generates a random r € Z*, computes the commitment y = r e (mod n) 
and sends y to the the verifier. In the second round, the verifier sends a random /-bit challenge a to the 
prover. In the third round, the prover computes and sends to the verifier z = rs a . To check, the verifier 
computes y' = z e v u and checks if y = y' (and y ^ (mod n)). 

The scheme's security is based on the assumption that computing roots modulo composite n is infeasible 
without knowledge of its factors, and can be proven using Lemma 3.2. Informally, if the prover can answer 
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algorithm GQ.key(&,Z) 
Generate random [&/2]-bit 


algorithm GQ.sign(M, (n, s,e)) 

r -£- Z* 




primes pi,P2 


y <— r e mod n 




n «- pip 2 
s^Z* 


a^H(y,M) 
z <— rs u mod n 




e A [2 l ,2 l+1 ), s.t. gcd(e, c/)(n)) = 1 
v <— l/s e mod n 
SK <— (n, s, e) 

PK <r- (n,v,e) 


return (z, a) 

algorithm GQ.vf(M,(n,v,e),(z,a)) 
if z = (mod n) then return 




return (SK , PK) 


y' <— z e v u mod n 

if a = H(y,M) then return 1 else return 






Figure 1: The GQ Signature Scheme 
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two different challenges, u and r, for the same y, then it can provide z a and z T 
Hence, v cr ~ T = (z a /z T ) e . Note that e is I + 1-bits long, hence e > \a — r|, hence g = gcd(cr — r, e) < e, 
so r = e/g > 1. By Lemma 3.2, knowing v,a — r,z a /z T and e allows one to efficiently compute the r-th 
root of v (to apply the lemma, we need to have g relatively prime with the order <j)(n) of the multiplicative 
group Z*, which is the case by construction, because e is picked to be relatively prime with 4>(n)). Thus, 
the prover must know at least some root of v (in fact, if e is picked to be prime, then the prover must know 
precisely the e-th root of v, because g = 1 and r = e). Note that it is crucial to the proof that e > 2 l and e 
is relatively prime with <j)(n). 

The standard transformation of [FS86] can be applied to this identification scheme to come up with the 
GQ signature scheme, presented in Figure 1. Essentially, the interactive verifier's /-bit challenge a is now 
computed using a random oracle (hash function) H : {0, 1}* — > {0, 1} L applied to the message M and the 
commitment y. 

4 Our scheme 



4.1 Main ideas for forward security 

The main idea for our forward- secure scheme is to combine the GQ scheme with Shamir's observation 
(Lemma 3.2). Namely, let e\, e2, . . . , &t be distinct integers, all greater than 2 ; , all pairwise relatively prime 
and relatively prime with <j)(n). Let s\, S2, . . . , st be such that s\ l = 1/v (mod n) for 1 < % < T. In time 
period i, the signer will simply use the GQ scheme with the secret key (ra,Sj,ej) and the verifier will use 
the GQ scheme with the public key (n, v, ei). Intuitively, this will be forward- secure because of the relative 
primality of the e^'s: if the forger breaks-in during time period b and learns the e^-th, e(,_|_i-th, . . . , ey-th 
roots of v, this will not help it compute e^-th root of v for j < b (nor, more generally, the r-th root of v, 
where r\ej). 

This idea is quite simple. However, we still need to address the following two issues: how the signer 
computes the s$'s and how both the signer and the verifier compute the e^'s. 

Computing s$'s. Notice that if the signer were required to store all the Sj's, this scheme would require 
secret storage that is linear in T. However, this problem can be easily resolved. Let fi = e$ ■ e$+i ■ . . . ■ ey. Let 
t{ be such that t\ % = 1/v (mod n). During the j-th time period, the signer stores Sj and ij+i- At update 



time, the signer computes Sj + \ 



£-■44 mod n and tj + 2 



tj+i mod n. This allows secret storage that is 



independent of T: only two values modulo n are stored at any time. It does, however, require computation 
linear in T at each update, because of the high cost of computing Sj + \ from tj + \. 

We can reduce the computation at each update to be only logarithmic in T by properly utilizing pre- 
computed powers of ij+i- This will require us, however, to store (21gT — 1) secrets instead of just two. 
Because this optimization concerns only the efficiency of the update algorithm and affects neither the other 
components of the scheme nor the proof of security, we present it separately in Section 5.2. 

Computing e^'s. In order for the scheme to be secure, the e^'s need to be relatively prime with each 
other 4 and with cj)(n), and greater than 2 l . The signer can therefore generate the e^'s simply as distinct 
(I + l)-bit primes. Of course, to store all the e^'s would require linear in T (albeit public) storage. However, 
the signer need only store ej for the current time period j, and generate anew the other e^'s for i > j during 
key update. This works as long as the signer uses a deterministic algorithm for generating primes: either 
pseudorandom search or sequential search from fixed starting points. The fact that e^'s are not stored but 
rather recomputed each time slows down the update algorithm only (and, as we show in Section 4.3, not 
by much). Note that the way we currently described the update algorithm, for the update at time period j 
the signer will need to compute ej+i, . . . , ey. With the optimization of Section 5.2, however, only at most 
(2 lgT — 2) of the e^'s will need to be computed at each update. 

We have not yet addressed the issue of how the verifier gets the e^'s. Of course, it could simply generate 
them the same way that the signer does during each key update. However, this will slow down verification, 
which is undesirable. The solution is perhaps surprising: the verifier need not know the e^'s at all! The 
value of ej can be simply included by the signer in every signature for time period j. Of course, a forger 
is under no obligation to include the true ej. Therefore, to avoid ambiguity, we will denote by e the value 
included in a signature. It may or may not actually equal ej. 

After some consideration, it becomes clear that e should satisfy the following requirements for security 
of the scheme: 

1. e should be included as an argument to the hash function H, so that the forger cannot decide on e 
after seeing the challenge a; 

2. e should be greater than 2 l , for the same reasons as in the GQ scheme; 

3. e should be relatively prime with (p(n), for the same reasons as in the GQ scheme; and 

4. e should be relatively prime with the eb,...,ex (where b is the break-in time period), so that the 
knowledge of the root of v of degree ej • e^+i ■ ■ ■ ■ ■ ey does not help the forger compute any root of v 
of degree r\e. 

The first two conditions can be easily enforced by the verifier. The third condition can be enforced by having 
n be a product of two primes pi,P2 that are of the form pi = 2% + 1, where q is prime. Then the verifier 
simply needs to check that e is odd (then it must be relatively prime with 4>{n) — otherwise, it would be 
divisible by q\, qi or q\qi, which would imply that the forger could factor n) . But how can the verifier 
check the last condition without knowing b and the actual values of ej, . . . , ey? The idea is to split the entire 
interval between 2 l and 2 l+l into T consecutive buckets of size 2 l jT each, and have each ej be a prime coming 
from the «-th bucket. Then the verifier knows that the actual values ej + \, . . . , ex are all at least 2 ; (1 + j/T) 
and prime. Thus, as long as e in the signature for time period j is less than 2 ; (1 + j/T), it is guaranteed to 
be relatively prime with e^+i, . . . , ex, and hence with ej, . . . , ey (because b > j). So all the verifier needs to 
check is that e is odd, is between 2 l and 2 ; (1 + j/T) and is included in the hash computation. 

4 In fact, this requirement can be relaxed. We can allow the e^'s not to be pairwise relatively prime, as long as we redefine 
fi as fi = lcm(/j, fi+i, . . . , /t), and require that e, be relatively prime with 4>{n) and ei/gcd(ej, fi+i) > 2 . However, we see 
no advantages in allowing this more general case; the disadvantage is that the e^'s will have to be longer to satisfy the last 
requirement, and thus the scheme will be less efficient. 



4.2 The scheme 

Our scheme (called IR) based on these ideas is presented in Figure 2. As in the GQ scheme, let H : {0, 1}* — > 
{0, 1} ; be a hash function. 

4.3 Efficiency 

Signing and Verifying. The strength of our scheme is in its signing and verifying performance. Both 
are the same as the already efficient ordinary GQ scheme (signing has the additional, negligible component 
of testing whether e is in the right range and odd). Namely, they each take two modular exponentiations, 
one modular multiplication and an application of H, for a total time of 0(k 2 l) plus the time required to 
evaluate H. (Note that, just like the GQ scheme, one of the two modular exponentiations for signing can 
be done off-line, before the message is known; also, one of the two modular exponentiations for verifying is 
of a fixed base v, and can benefit from precomputation.) 

Key Generation and Update. We need to make strong assumptions on the distributions of primes in 
order to estimate efficiency of key generation and update algorithms. First, we assume that at least one 
in 0(k) \k/2~\-bit numbers is a prime, and that at least one in O(k) of those is of the form 2q + 1, where 
q is prime. Then, generating n takes 0(k 2 ) primality tests. Each primality test can be done in 0(k s ) bit 
operations [BS96], for a total of 0(k 5 ) bit operations. Similarly, we will assume that at least one in 0(1) 
integers in each bucket [2 ; (1 + (i — 1)/T),2 l (l + i/T)) is a prime, so generating each e^ takes 0(l 4 ) bit 
operations. 

In addition to generating n and the e^'s, key generation needs to compute the product of the e^'s 
modulo <fi(n), which takes 0(Tkl) bit operations, and three modular exponentiations, each taking 0(k 2 l) 
bit operations. Therefore, key generation takes 0(k 5 + l 4 T + k 2 l + klT)) bit operations. 

Key update cannot multiply all the relevant e^'s modulo <fi(n), because (p(n) is not available (otherwise, the 
scheme would not be forward-secure). Therefore, it has to perform 0(T) modular multiplications separately, 
in addition to regenerating all the e^'s. Thus, it takes 0(k 2 lT + l 4 T) bit operations. 

Note that the l 4 T component is present in the running time for the update algorithm because of the 
need to regenerate the e^'s each time. However, for practical values of I (on the order of 100) and k (on the 
order of 1000), l 4 T is roughly the same as k 2 lT, so this only slows down the key update algorithm by a small 
constant factor. Moreover, in Section 5.1 we show how to reduce the l 4 T component in both key generation 
and update to (I 2 + lg 4 T)T (at a very slight expense to signing and verifying). 

Finally, as shown in Section 5.2, if we are willing to increase secret storage to roughly 2klgT, then 
we can replace the factor of T in the cost of update by the factor of lgT, to get update at the cost of 
0((l 4 + k 2 l) lgT) (or, if optimization of Section 5.1 is additionally applied, 0((k 2 l + I 2 + lg 4 T) lgT)). 

Sizes. All the key and signature sizes are comparable to those in the ordinary GQ scheme. 

The public key has I + 1 fewer bits than the GQ public key, and the signatures have I + 1 more bits, 
because e is included in the signature rather than in the public key. In addition, both the public key and the 
signature have lg T more bits in order to accommodate T in the public key and the current time period in 
the signature (this is necessary in any forward- secure scheme). Thus, the total public key length is 2k + \gT 
bits, and signature length is k + 21 + 1 + lgT bits. Optimization of Section 5.1 shortens the signatures 
slightly, replacing I + 1 of the signature bits with roughly lgT bits. 

The secret key is k + 2 lgT + \seed\ bits longer than the GQ scheme in order to accommodate the current 
time period j, the total time periods T, the value tj + \ necessary to compute future keys and the seed 
necessary to regenerate the e^'s for i > j. Thus, the total secret key length is 3k + I + 1 + \seed\ + 2 lgT bits 
(note that only 2k of these bits need to be kept secret). If the optimization of Section 5.2 is used, then the 
secret key length increases by roughly 2k\gT bits, all of which need to be kept secret. 



algorithm IR.key(A), l,T) 

Generate random \k/2] — 1-bit primes q\, qi such that pi = 2% + 1 are both prime 
n «- pip 2 

h£z* 

Generate primes e { such that 2*(1 + (« - 1)/T) < e* < 2*(1 + i/T) for i = 1, 2, . . . , T. 

(This generation is done either deterministically or using a small seed seed and 

i? as a pseudorandom function.) 
H <— e2 • • • • • ey mod (</>(n)) (where r/>(n) = 45152) 
si <— t{ 2 mod n 
v <— 1/s^ 1 mod n 
£2 •<— ^i 1 mod n 
5A"i •<— (l,T,n,si, i2 5 ei, seed) 
P# <- (n, «, T) 
return [SK U PK) 



algorithm IR.update(5 , _£\ j) 

Let 5i^j = (j,T,n,Sj,tj + i,ej,seed) 

if j = T then return e 

Regenerate ej+i, . . . , ex using seed 

Sj + i «- £ -^ mod n; tj +2 <- t- 3 ^ mod n 

return SKj + \(j + 1, T, n, Sy+i, £7+2, ej+i, seed) 



algorithm IR.sign(M, SKj) 

Let SKj = (j,T,n,Sj,tj + i,ej,seed) 



r^Z* n 



y <— r e J mod n 
a^H{j, ej ,y,M) 
z <— rs a mod n 
return (z,a,j,ej) 



algorithm \R.vf(M,PK,(z,a,j,e)) 
Let PK = (n, v) 

if e > 2'(1 + j/T) or e < 2' or e is even then return 
if z = (mod n) then return 
y' <— z e v u mod n 
if a = H(j,e,y,M) then return 1 else return 



Figure 2: Our forward-secure signature scheme (without efficiency improvements) 



in 



4.4 Security 

The security of our scheme (in the random oracle model) is comparable to the security of the schemes of 
[BM99, AROO]. The proof closely follows the one in [AROO], combining ideas from [PS96, BM99, MR99]. 

First, we state the following theorem that will allow us to upper-bound the insecurity function. The full 
proof of the theorem is very similar to the one in [AROO] and is contained in Appendix A. 

Theorem 4.1 Given a forger F for IR[/c, I, T] that runs in time at most t, asking at most qtash hash queries 
and q s i g signing queries, such that Succ wslg (IR[&, l,T], F) > s, we can construct an algorithm A that, on 
input n (a product of two safe primes), a € Z* and I, runs in time t' and outputs (j3, r) such that 1 < r < 2 l+l 
and f3 r = a (mod n) with probability e', where 

t' = 2t + 0{lT{l 2 T 2 + k 2 )) 
, _ (£-2 2 - fc g sig (g hash + l)) 2 e - 2 2 - fc g sig (g hash + 1) 



T 2 (q hash + 1) 2'T 



Proof Idea. A will use F as a subroutine. (Note that A gets to provide the public key for F and to answer 
its signing and hashing queries.) A bases the public key v on a as follows: it randomly guesses j between 1 
and T, hoping that F's eventual forgery will be for the j-th time period. It then generates e\, . . . , ey just like 
the real signer, sets tj + \ = a and computes »as» = l/^+i 1 m od n, where, as above, / J+ i = e.j + \ ■ . . . ■ ey. 

Then A runs F. Answering F's hash and signature queries is easy, because A fully controls the random 
oracle H. If ^4's guess for j was correct, and F indeed will output a forgery for the j-th time period, 
then F's break-in query will for the secret of a time period b > j. A can compute the answer as follows: 
h+i = tj+l = a e ^'-' eb and Sb = t b b+1 = a e ji----- e b-i-eb+i-----er ^he other components of SK^ are not secret, 
anyway). Suppose j4's guess was correct, and in the end F outputs a signature (z,a,j,e) on some message 
M. We will assume that F asked a hash query on (y,M, j, e) where y = z e v a mod n (if not, A can make 
that query for F). 

Then, A runs F the second time with the same random tape, giving the same answers to all the oracle 
queries before the query (y, M,j, e). For (y, M,j, e), A gives a new answer r. If F again forges a signature 
(z',r,j,e) using the same hash query, we will have that y = z e v a = z' e v T (mod n), so (z/z') e = v T ~ a = 
Qf /j+i(' 7 - T ) (mod n). Note that because e is guaranteed to be relatively prime with fj+i, and a — r has 
at least one fewer bit than e, gcd(fj+i(a — r),e) = gcd(cr — r, e) < e (as long as a ^ r). Thus, r = 
e/gcd(/j + i(r — er), e) > 1 and, by Lemma 3.2, A will be able to efficiently compute the r-th root of a. 

Please refer to Appendix A for further details. I 

This allows us to state the following theorem about the insecurity function of our scheme. 

Theorem 4.2 For any i, g s ; g , and qtash, 

InSec iwsi mR[k,l,T];t,q sig ,q h3sh )< 



T^J(q hash + l)InSec SRSA (k,Lt')+2- l+1 T(q hash + 1) + 2 2 - fe gr sig ( (/hash + 1) , 
where t' = 2t + 0(lT(l 2 T 2 + k 2 )). 

Proof: The insecurity function is computed simply by solving for (e — 2 2_ * ; g s jg((ft 1 ash + 1))/T the quadratic 
equation in Theorem 4.1 that expresses e' in terms of e to get 



£ - 2 i -Ssig(ghash + 1))/T = 2- l (q hash + 1) + j2- 2l (q hash + l) 2 + e'(q hash + 1 



< 2 l (q hash + 1) + ^2- 2l (q hash + l) 2 + Ve'{q hash + 1) 



2 m (ghash + l) + vV(«hash + l), 
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and then solving the resulting inequality for e. | 

5 Further Improving Efficiency 

5.1 Finding the ej's faster 

Finding ej's takes time because they need to be I + 1-bit primes. If we were able to use small primes instead, 
we could search significantly faster, both because small primes are more frequent and because primality tests 
are faster for shorter lengths. 5 

We cannot use small primes directly because, as already pointed out, the ej's must have at least I + 1 
bits. However, we can use powers of small primes that are at least I + 1 bits. That is, we let ej be a small 
prime, 7r(e.;) be such that ^l > 2 l and ej = e\ ^ . As long as ir is a deterministic function of its input e 
(for example, 7r(e) = l/[log 2 ej), we can replace e in the signature by e, and have the verification algorithm 
compute e = e^^' . 

Of course, the verification algorithm still needs to ensure that e is relatively prime to (p(n) and to 
ej, . . . , ey. This is accomplished essentially the same way as before: we divide a space of small integers into 
T consecutive buckets of some size S each, and have each ej come from the i-th bucket: ej € [(i — l)S,iS). 
Then, when verifying a signature for time period j, it will suffice to check that e is odd and comes from a 
bucket no greater than the j-th: e < jS. It will be then relatively prime to ej, . . . , ey, and therefore e = e 71 "^) 
will be relatively prime to ej, . . . , ey. 

When we used large primes, we simply partitioned the space of (I + l)-bit integers into large buckets, of 
size 2 l jT each. We could have used smaller buckets, but this offered no advantages. However, now that we 
are using small primes, it is advantageous to make the bucket size S as small as possible, so that even the 
largest prime (about TS) is still small. 

Thus, to see how much this optimization speeds up the search for the ej's, we need to upper-bound 
S. S needs to be picked so that there is at least one prime in each interval [(i — l)S,iS) for 1 < i < T. 
It is reasonable to conjecture that the distance between two consecutive primes P n and P n +i is at most 
(In P n ) [BS96]. Therefore, because the largest prime we are looking for is smaller than TS, S should be 
such that S > In 2 TS. It is easy to see that S = 41n 2 T will work for T > 75. (As a practical matter, 
computation shows that S = 282 will work for T up to about 3.5 million, because the largest gap between 
consecutive primes up to 1 billion is 282.) Thus, the ej's are all less than 4Tln 2 T, and therefore the size 
of each ej is O(logT) bits. Thus, finding and testing the primality of the ej's and then computing the ej's 
takes 0(T(log 4 T + I 2 )) time, as opposed to 0{TI A ) without this optimization. 

The resulting scheme will slightly increase verification time: the verifier needs to compute e from e. This 
takes time 0(l 2 ) (exponentiating any quantity to obtain a roughly (I + l)-bit quantity takes time 0(l 2 )), 
which is lower order than 0(k 2 l) verification time. Moreover, it will be impossible to get ej to be exactly 
I + 1 bits (it will be, on average, about I + (logT)/2 bits). This will slow down both verification and signing, 
albeit by small amounts. Therefore, whether to use the optimization in practice depends on the relative 
importance of the speeds of signing and verifying vs. the speeds of key generation and update. 

5.2 Optimizing key update 

The key update in our scheme requires computing Sj such that s^ = 1/v mod n. Knowledge of Sj-i, such 
that SjlY = l/i> mod n, does not help, because ej and ej_i are relatively prime. The easiest way to compute 
Sj requires knowledge of (f>(n): Sj <— X/v 1 ^* mod ^ n > mod n. However, the signer cannot store the factors of 
n — otherwise the forger would obtain these factors during a break-in, and thus be able to produce the past 

6 In fact, when a table of small primes is readily available (as it often is for reasonably small T), no searching or primality 
tests are required at all. 
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periods' secrets (and signatures). The factors of n can be used only during the initial key generations stage, 
after which they should be securely deleted. 

To enable generation of current and future s$'s without compromising the past ones, we had defined 
(in Section 4) a secret ti for time period i, from which it was possible to derive all future periods' secrets 
Sj>i. The update of ti to ij+i can be implemented efficiently (1 exponentiation). However, in this approach 
the computation of each s$ from £$ requires 0(T — i) exponentiations. This computation can be reduced 
dramatically if the storage is increased slightly. 

Specifically, in this section we demonstrate how replacing the single secret £$ with log 2 T secrets can 
reduce the complexity of the update algorithm to only log 2 T exponentiations. 

Abstracting the Problem. Consider all subsets of Z T = {1,2, .. . , T}. Let each such subset S corre- 
spond to the secret value ts = t 1 ' is ' . For example, t\ corresponds to Zt, ti corresponds to {i, i + 1, . . . , T}, 
v~ l corresponds to the empty set, and each si corresponds to the singleton set {«}. Raising some secret 
value ts to power e% corresponds to dropping i from S. 

Thus, instead of secrets and the exponentiation operation, we can consider sets and the operation of 
removing an element. Our problem, then, can be reformulated as follows: design an algorithm that, given 
Zt, outputs (one-by-one, in order) the singleton sets {i} for 1 < i < T. The only way to create new sets 
is to remove elements from known sets. The algorithm should minimize the number of element-removal 
operations (because they correspond to the expensive exponentiation operations). 

Fairly elementary analysis quickly demonstrates that the most efficient solution for this problem (at least 
for T that is a power of 2) is the following divide-and-conquer algorithm: 

Input: An ordered non-empty set A. 
Output: Singleton sets {x}, for x € A, in order. 
Steps: If A has one element, output A and return. 

Remove the second half of j4's elements to get B. 

Recurse on B. 

Remove the first half of j4's elements to get C. 

Recurse on C. 

This algorithm takes exactly Tlog 2 T element-removal operations to output all the singletons. Moreover, 
the recursion depth is 1 + log 2 T, so only 1 + log 2 T sets need to be stored at any time (each set is just a 
consecutive interval, so the bookkeeping about what each set actually contains is simple). 

This recursive algorithm can essentially be the update algorithm for our scheme: at every call to update, 
we run the recursive algorithm a little further, until it produces the next output. We then stop the recursive 
algorithm, save its stack (we need to save only log 2 T secrets, because the remaining one is the output of 
the algorithm), and run it again at the next call to update. A little more care needs to be taken to ensure 
forward- security: none of the sets stored at time period i should contain elements less than i. This can 
be done by simply removing i from all sets that still contain in (and that are still needed) during the «-th 
update. The total amount of work still does not change. 

Because there are T calls to update (if we include the initial key generation), the amortized amount of 
work per update is exactly log 2 T exponentiations. However, some updates will be more expensive than 
others, and update will still cost @(T) exponentiations in the worst case. We thus want to improve the 
worst-case running time of our solution without increasing the (already optimal) total running time. This 
can be done through pebbling techniques, described below. 

Pebbling. Let each subset of Zt correspond to a node in a graph. Connect two sets by a directed edge 
if the destination can be obtained from the source by dropping a single element. The resulting graph is 
the T-dimensional hypercube, with directions on the edges (going from higher-weight nodes to lower-weight 
nodes). We can traverse the graph in the direction given by the edges. We start at the node corresponding 
to Zt, and need to get to all the nodes corresponding to the singleton sets {«}. 
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One way to accomplish this task is given by the above recursive algorithm, which has the minimal total 
number of steps. However, we would like to minimize not only the total number of steps, but also the number 
of steps taken between any two "consecutive" nodes {«} and {i + 1}, while keeping the memory usage low. 
We will do this by properly arranging different branches of the recursive algorithm to run in parallel. 

To help visualize the algorithm, we will represent each set stored as a pebble at the corresponding node 
in a graph. Then removing an element from a set corresponds to moving the corresponding pebble down the 
corresponding directed edge. The original set may be preserved, in which case a "clone" of a pebble is left at 
the original node, or it may be discarded, in which case no such clone is left. Our goal can be reformulated 
as follows in terms of pebbles: find a pebbling strategy that, starting at the node Zt, reaches every node {«} 
in order, while minimizing the number of pebbles used at any given time (this corresponds to total secret 
storage needed), the total number of pebble moves (this corresponds to total number of exponentiations 
needed), and the number of pebble moves between any two consecutive hits of a singleton (this corresponds 
to the worst-case cost of the update algorithm). 

The Pebbling Algorithm. We shall assume that T > 1 is a power of 2. The following strategy uses at 
most 1 + log 2 T pebbles, takes Tlog 2 T total moves (which is the minimum possible), and requires at most 
log 2 T moves per update. 

Each pebble has the following information associated with it: 

1. its current position, represented by a set P C Zt (P will always be a set of consecutive integers 

\ P min j • • • j P max j ) ! 

2. its "responsibility," represented by a set R C P (R will also always be a set of consecutive integers 
{R m in , • • • , -Rmax }', moreover \R\ will always be a power of 2). 

Each pebble's goal is to ensure that it (together with its clones, their clones, etc.) reaches every singleton 
in its set P. If R C P, then the pebble can move towards this goal by removing an element from P. If, 
however, R = P, then the pebble has to clone (unless \P\ = \R\ = 1, in which case it has reached its 
singleton, and can be removed from the graph). Namely, it creates a new pebble with the same P, and 
responsibility set R' containing only the second half of R. It then changes its own R to R — R' (thus dividing 
its responsibility evenly between itself and its clone). Now both the pebble and the clone can move towards 
their disjoint sets of singletons. 

We start with a single pebble with P = R = Zt- The above rules for moving and cloning ensure that 
the combined moves of all the pebbles will be the same as in the recursive algorithm. Thus, the steps of the 
pebbles are already determined. We now have to specify the timing rules: namely, when the pebbles take 
their steps. A careful specification is important: if a pebble moves too fast, then it can produce more clones 
than necessary, thus increasing the total memory; if a pebble moves too slowly, then it may take longer to 
reach its destination singletons, thus increasing the worst-case cost of update. 

In order to specify the timing rules, we will imagine having a clock. The clock "ticks" consecutive integer 
values, starting with — T/2 + 1. After each clock tick, each pebble will decide whether to move and, if so, 
for how many moves, as follows: 

1. The original pebble always makes two moves per clock tick, until it reaches the singleton {1}. After 
reaching the singleton it stops, and then removes itself from the graph on the next clock tick. 

2. After a new pebble is cloned with responsibility set R, it stays still for [|P|/2] clock ticks. After 
[~|Pi|/2]-th clock-tick following its birth, it starts moving at one move per clock tick. After \R\ such 
moves, it starts moving a two moves per clock tick, until it reaches its leftmost singleton. After reaching 
the singleton it stops, and then removes itself from the graph on the next clock tick. 

We remark that the above rules may seem a bit complex. Indeed, simpler rules can be envisioned: for 
example, allowing each pebble at most one move per clock tick, and specifying that each pebbles moves 

14 



following a given clock tick only if it absolutely has to move in order to reach its leftmost singleton on time. 
However, this set of rules will require roughly 2 log 2 T pebbles (even though at most log 2 T of them will be 
moving at any given time). Having pebbles move at variable speeds allows us to delay their cloning, and 
thus reduces the total number of pebbles, as shown by the following theorem. 

Theorem 5.1 Suppose T > 1 is a power of two. If % is the value most recently ticked by the clock, then the 
total number of pebbles under the above rules never exceeds 1+ |_log 2 (T — %)\ (if % > 0) or (log 2 T) — [log 2 — i\ 
(if — T < i < 0). The number of moves occurring immediately following the clock tick i also never exceeds 
this quantity. For each i, 1 < i < T, a pebble reaches the singleton i + \ immediately before the clock ticks 
the value i + 1, and is removed before the clock ticks i + 2. 

Proof: The proof is by induction on log 2 T. 

For T = 2, we start with a single pebble with P = R = {1,2}. After the clock ticks 0, this pebble clones 
the pebble with R' = 2, and itself moves to P = {1}. The clone waits for one clock tick and then, after the 
clock ticks 1, the clone moves to P = {2}. 

Suppose the statement is true for some T that is a power of two. We will now prove it for T' = 2T. 
After clock tick — T + 1, we have two pebbles: one responsible for {1, . . . , T}, and the other responsible for 
{T + 1, . . . , 2T}. For the next T/2 — 1 clock ticks, the first pebble will move at two steps per tick, and the 
second one will stay put (thus, the number of moves does not exceed the number of pebbles). After the 
clock ticks —T/2, the first pebble will arrive at position P = {1, . . . , T}. Thus, starting at t = — T + 1, the 
inductive hypothesis applies to the all the pebbles that will cover the first half of the singletons: there is a 
single pebble until t = —T/2 + 1 and it is in position P = {1, . . . , T} after clock tick —T/2 + 1. 

The second pebble will reach the position P' = {2,...,T} after the clock ticks T/2. Thus, again, after 
the clock ticks 1, the inductive hypothesis applies to all the pebbles that will cover the second half of the 
singletons, except that time is shifted forward by T. That is, if 1 < i < T, then the number of pebbles in 
the second half does not exceed (log 2 T) — |_log 2 (T — i)\, and if t > T, then the number of pebbles in the 
second half does not exceed 1 + |_log 2 (2T — i)\ . 

The key to finishing the proof is to realize that the first half will lose a pebble just as the second half gains 
one. To be precise, we can consider the following four cases. 

• For — T < i < 0, we have (log 2 T) — [log 2 — i\ pebbles in the first half (by the inductive hypothesis), 
and one pebble in the second half, so we have a total of (log 2 2T) — [log 2 — i\ pebbles, as required. 

• For % = 0, we have 1 + log 2 T = log 2 2T pebbles in the first half (by the inductive hypothesis), and one 
pebble in the second half, for a total of 1 + log 2 2T pebbles, as required. 

• For < i < T, we have 1 + Llog 2 (T - i)\ pebbles in the first half and (log 2 T) - Llog 2 (T - i)\ pebbles 
in the second half (both by the inductive hypothesis), for a total of 1 + log 2 T = 1 + [log 2 (2T — i)\ 
pebbles, as required. 

• For % > T, we have no pebbles in the first half and [log 2 (2T — i)\ pebbles in the second half (by the 
inductive hypothesis), as required. 

It is easy to see that in each of the above four cases, the number of moves does not exceed the number of 
pebbles (because for every pebble moving at two steps per clock tick, there exists a pebble that is standing 
still — namely, its most recent clone). I 

Security. It is, of course, crucial to ensure that the above changes to the update algorithm do not 
compromise the security of our scheme. It suffices to prove that every secret stored following the clock tick 
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i can be derived in polynomial time from ij+i. In other words, it suffices to prove that, following the clock 
tick i, no pebble's position P satisfies JgP. This can be easily done by induction, as long as each pebble 
moves towards its goal by removing the smallest possible element from its position P (the inductive step 
is proved as follows: if 2T is the total number of time periods, then the single pebble responsible for the 
second half of the singletons will have removed {1, . . . , T/2} from its position following the clock tick 1, and 
will have removed {1, . . . , T} following the clock tick T/2 + 1). 
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A Details of the Proof of Theorem 4.1 

First, we assume that if F outputs (z,a,j,e) as a forgery, then the hashing oracle has been queried on 
(j,e,y,M), where y = z e v u mod n (any adversary can be modified to do that; this may raise the number 
of hash queries to (/hash + 1-) We will also assume that F performs the necessary bookkeeping and does not 
ask the same hash query twice. 6 Note that F may ask the same signature query twice, because the answers 
will most likely be different. 

Recall that j4's job, given a and n, is to find (with F's help) (3 and r > 1 such that beta!' = a 
(mod n). First, A has to guess the time period for which F will output the forgery: it randomly selects j, 
1 < j < T (sometimes A may also succeed if the forgery is for a time period % < j, but this not necessary 
for our argument). A then generates e\, . . . ,ex just like the real signer, sets tj + \ = a and computes v as 
v = l/t-^l mod n, where, as above, fj + \ = ej+i • . . . • ey. 

A then comes up with a random tape for F, remembers it, and runs F on that tape and the input public 
key (n,v,T). If F breaks in at time period b, then A can provide F with the secret key as long as b > j: 
knowing tj + \ will allow A to compute Sb and £&+i. If 6 < j, then A aborts (because, in particular, F's 
forgery cannot be for time period j in that case). 

To answer F's signature and hash queries, A maintains two tables: a signature query table and a hash 
query table. 

Signature queries can be answered almost at random, because A controls the hash oracle. In order to 
answer a signature query number s on a message M s during time period j s , A selects a random z s € Z* and 
<j s € {0, 1} ; , computes y s = z s e ^v Us , and checks its signature query table to see if a signature query on M s 
during time period j s has already been asked and if y s used in answering it. If so, A changes z s and a s to 
the z and a that were used in answering that query. Then A adds the entry (s,j s ,ej s ,y s ,a s ,z s ,M s ) to its 
signature query table and outputs (z s , a s , j s , ej s ). 

Hash queries are also answered at random. To answer the i-th hash query (y' t ,Ml,j' t ,e' t ), A first checks 
its signature query table to see if there is an entry (s,j s ,ej s ,y s ,a s ,z s ,M s ) such that (y s ,M s ,j s ,ej s ) = 

6 This may slightly increase the running time of F, but we will ignore costs of simple table look-up for the purposes of this 
analysis. 
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(y' t , Ml,j' t , e' t ). If so, it just outputs a s . Otherwise, it picks a random a' t € {0, 1} ; , records in its hash query 
table the tuple (t,y' t ,Ml,j' t ,e' t ,a' t ) and outputs a' t . 

Assume now the break-in query occurs during time period b > j, and the valid forgery (z, a, i, e) is output 
for a time period % < j (if not, or if no valid forgery is output, A fails). Let y = z e v a . Because we modified 
F to first ask a hash query on (y, M, i, e), we have that, for some h, (h, y, M, i, e, a) = (h, y' h , M' h , j' h , e' h , a' h ) 
in the hash query table (it can't come from the signature query table, because F is not allowed to forge a 
signature on a message for which it asked a signature query). A finds such an h in its table and remembers 
it. 

A now resets F with the same random tape as the first time, and runs it again, giving the exact same 
answers to all F's queries before the h-th hash query (it can do so because it has all the answers recorded 
in the tables). Note that this means that F will be asking the same h-th hash query (y, M, i, e) as the first 
time. As soon as F asks the h-th hash query, however, A stops giving the answers from the tables and comes 
up with new answers at random, in the same manner as the first time. Let r be the new answer given to 
the h-th hash query, and assume r 7^ a. 

Assume again the break-in query occurs during time period b > j, and the valid forgery (z',a',i',e') is 
output for a time period i' < j. A again computes y' = z' e v s%9ma ; by the same reasoning as before, F had 
to ask a hash query on (y', M', i', e'). Let h! be the number of that query. A finds h! and fails if h! 7^ h. If, 
however, h' = h, then (y, M, i, e) = (y', M', «', e'), simply because the h-th hash query had to be the same in 
both runs of F. Also then a' = r. Therefore, 

z e v a = z' e v T =>► {z/z'f = v T - a = a^ 1 ^-^ (mod TV). 

Note that because e is guaranteed to be relatively prime with fj + \ (as long as i < j), and a — r 
has at least one fewer bit than e, gcd(/j + i(cr — r),e) = gcd(cr — r, e) < e (as long as a / r). Thus, 
r = e/gcd(/ J+ i((T — t), e) > 1 and, by Lemma 3.2, A will be able to efficiently compute the r-th root of a. 

Running Time Analysis. A runs F twice. Preparing the public key and answering hashing and signing 
queries takes A no longer than it would take the real oracles (ignoring the costs of table look-ups). To 
find which hashing query the signature corresponds to and to apply Lemma 3.2 takes 0(lT(l 2 T 2 + k 2 )) bit 
operations. 

Probability Analysis. We will need the following lemma in our analysis. 

Lemma A.l Let a\,a2, ■ ■ ■ ,ci\ be real numbers. Let a = ^„ =1 a^- Let s = ^„ =1 aft- Then s > ^-. 

Proof: Let b = a/X and b^ = b — a^. Note that ^„ =1 b^ = Xb — ^„ =1 a^ = a — a = 0. Then 

A A 



11=1 11=1 



Ej=i K = Xb- £j =1 a, = a- 


- a = 


A A 
Xb 2 -2&^^ + ^&2> A6 2 ! = 


a 2 
= X 
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First, consider the probability that j4's answers to F's oracle queries are distributed as those of the true 
oracles that F expects. This is the case unless, for some signature query, the hash value that A needs to 
define has already been defined through a previous answer to a hash query (call this "j4's failure to pretend"). 
Because z is picked at random from Z n *, z e v a is a random element of Z*. The probability of its collision with 
a value from a hash query in the same execution of F is at most (qtash + 1)/|Z*| thus, the probability (taken 
over only the random choices of A) of j4's failure to pretend is at most <? s ig(<?hash + l)/|-^nl ^ ( 7sig(<7hash + l)2 2_ ' c 
(because \Z*\ = 4q\q2 > 2 k ~ 2 ). This is exactly the amount by which F's probability of success is reduced 
because of interaction with A rather than the real signer. Let 8 = s — (feig(<7hash + l)2 2 ~ k - 
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Let eft be the probability that F produces a successful forgery and that its break-in query occurs in time 
period b. Clearly, S = ^6=2 £ b (if b = 1, then F cannot forge for any time period). Assume now that A 
picked j = b — 1 for some fixed b. The probability of that is 1/T. 

We will now calculate the probability of the event that F outputs a valid forgery based on the same hash 
query both times and that the hash query was answered differently the second time and that the break-in 
query was b both times. Let p^f, be the probability that, in one run, F produces a valid forgery based on 
hash query number h after break-in query in time period b. Clearly, 

gh ash + l 

e 6 = E Ph > b 
h=l 

Let Ph,b,s (f° r a sufficiently long binary string S of length m) be the probability that, in one run, F produces 
a valid forgery based on hash query number h after break-in query in time period 6, given that the string S 
was used to determine the random tape of F and the responses to all the oracle queries of F until (and not 
including) the /i-th hash query. We have that 

2 m Ph,b = E Ph,b,s- 
Se{o,i} m 

Given such a fixed string S, the probability that F produces a valid forgery based on the hash query number 
h after break-in query in time period b in both runs is p\ b s (because the first forgery is now independent 
of the second forgery). The additional requirement that the answer to the hash query in the second run be 
different reduces this probability to Ph,b,s{Ph,b,s — 2 _; ). Thus, the probability qh,b that F produces a valid 
forgery based on the hash query number h in both runs and that the answer to the hash query is different 
in the second run and that the break-in query was b in both runs is 

Qh,b = E 2 ">M,s(PM,s-2-*)=2- m E Ph,b,s -2-' E PM,s 
se{o,i} m \se{o,i} m se{o,i} m 

2- m (p hb 2 m ) 2 , 9 , 

^ 2% " 2~ W = Ph,b ~ 2- l Ph,b 

(by Lemma A.l). 

The probability that F outputs a valid forgery based on the same hash query both times and that the 
hash query was answered differently in the second run and that the break-in query occurred in time period 
i is now 

gh ash + l gh ash + 1 9hash + l 2 

£ q h ,b> £ Pl,b- E 2" l p h ,b > -^—r ~ 1~ l e b 

u 1 u i u i smash ~r J - 

h=l h=l h=l 

(by Lemma A.l). 

Note that if this happens, then the forgery occurs in time period i < b = j + 1 (because the forgery has 
to occur before the break-in query), so A will be able to take a root of a. 

Finally, we remove the assumption that A picked j = b — 1 as the time period to get the probability of 
j4's success: 



'4E 



T+ 1 / .2 X c2 



e 



2- l £6 > 



T ^ V<Zhash + 1 J ~ T 2 (g hash + 1) XT 



(by Lemma A.l). I 
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